Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-077

Text File | 1995-12-31 | 75KB | 2,103 lines

C.S.M.P. Digest             Mon, 02 Jan 95       Volume 3 : Issue 77

Today's Topics:

        AppleShare Volume or Local Volume?
        Default button in a modeless dialogue?
        How difficult to create an AS wrapper for porting?
        How to get Macintosh Name or Owner Name?
        How to receive events in AppleScript script?
        Jasik 12-08 Update available
        Mounting Appleshare Volumes
        PUZZLER: How to get to A5 world in _ExitToShell patch
        Password for mounting remote volumes
        SUMMARY: MacTCP Performance Problems
        [Q] How to find parameter info for traps
        string constants in Metrowerks C code resource?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (John M. Sully)
Subject: AppleShare Volume or Local Volume?
Date: Thu, 01 Dec 1994 10:55:08 -0600
Organization: Library Information Technologies - CWRU

Greetings,
   I need to figure out the following about a mounted volume and am not
sure what the "correct" way of doing it is...

(1) Is the volume on an Appleshare server?

an if so...

(2) What is the name of the server it is on?

Thanks,
John

--
- -------------------------------------------------------------------------
| John M. Sully                    | Freiberger Library | Yesterday's     |
| Software Maintenance and         |      Room 305      |    Technology   |
|    Development Specialist        | voice:[phone]| Solving Today's |
| Library Infomation Technologies  | fax:[phone]  |    Problems     |
| Case Western Reserve University  | [e-mail]  | Tomorrow        |
- -------------------------------------------------------------------------
|        <A HREF="http://x-wing.lit.cwru.edu/">John's Server  </A>        |
- -------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 12 Dec 1994 01:50:27 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (John M. Sully) writes:

>(1) Is the volume on an Appleshare server?
>
>an if so...
>
>(2) What is the name of the server it is on?

If you just want to find out if the volume is a network volume, call
PBHGetVolParms and look at the vMServerAdr volume returned in the
GetVolParmsInfoBuffer structure.  If vMServerAdr is non-zero, then the
volume is a netowork volume.

If you want to find out if a volume is mounted by the AppleShare foreign
file system, then you should first call PBGetVolMountInfoSize.  That will
return the size of the volume mount information record that
PBGetVolMountInfo will return.  Allocate a block big enough for the volume
mount information record and then call PBGetVolMountInfo to fill it in.
If the media field in the volume mount information record is
AppleShareMediaType, then the volume is an AppleShare volume and you can
get the server name out of the volume mount information record.

If you use the routines in Apple's sample code MoreFiles, this is made
pretty easy. For example:

OSErr result;
short infoSize;
short theFlags;
short theUAMType;
Str32 theZoneName, theServerName, theVolName, theUserName;

result = GetVolMountInfoSize(NULL, vRefNum, &infoSize);
if (result == noErr)
{
  Ptr  volMountInfo = NewPtr((Size)infoSize);
  if (volMountInfo != NULL)
  {
    result = GetVolMountInfo(NULL, vRefNum, volMountInfo);
    if (result == noErr)
    {
      result = RetrieveAFPVolMountInfo((AFPVolMountInfoPtr)volMountInfo,
&theFlags,
                                       &theUAMType, theZoneName,
theServerName,
                                       theVolName, theUserName);
      if (result == paramErr)
      {
        /* volume isn't an AFP volume (RetrieveAFPVolMountInfo returns
paramErr in this case) */
      }
    }
    DisposePtr(volMountInfo);
  }
}
else
{
  /* volume doesn't support volume mount calls so it isn't AppleShare
volume */
}

(the code above was typed in here but not test compiled)

Hope that helps...

- Jim Luther

---------------------------

>From [e-mail] (Ian McCall)
Subject: Default button in a modeless dialogue?
Date: 16 Dec 1994 16:02:44 -0600
Organization: UTexas Mail-to-News Gateway

Hi.

I'm trying to implement a modeless dialogue for the first time, and I've
come across a problem.

How do you implement default buttons in a modeless dialogue with editText
fields? I've got the button there, and I've framed it using the dummy
userItem method. However, I can't see how to make it understand that
pressing return/enter is the same as clicking on the OK button.

I'm calling IsDialogEvent, followed by DialogSelect in order to determine
which dialogue the event is for. Thing is, DialogSelect 'helpfully'
processes the event for me too. By the time I know both which key has been
pressed and which dialogue it was pressed in, DialogSelect has already
passed it on to the active TextEdit field.

I've used return/enter here as examples, but it's also happening when I try
to intercept escape for the 'cancel' button, and all the standard edit
combos (z, x, c, v). As sson as I try to find out which dialogue the
keypresses are in, the events get process anyway and I'm left with an
unwanted character sitting in my editText field.


Also, whilst I'm here, I'd like to ask for some help on pop-up menus under
System 7. I haven't got all the documentation, but apparently there's a
CDEF I can use in combination with PopUpMenuSelect(). Which CDEF is it,
please? And how would I go about determining that information? This pop-up
is to go in the same modeless dialogue as above, so I assume that what I
need to do is get a handle to the CDEF and then do a SetDItem call - is
that right?

Thanks in advance for any information. As I say, I've not done a modeless
dialogue box before and without having all the documentation to hand I'm
finding it a bit awkward.

Please reply via email, since I don't actually read this group very often.
It's just too big to use with an online reader and your own phone bill
ticking along in the background...


Cheers,
Ian

([e-mail])



+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Fri, 16 Dec 1994 21:43:32 -0500
Organization: One Step Beyond

[e-mail] (Ian McCall) wrote:

) How do you implement default buttons in a modeless dialogue with editText
) fields? I've got the button there, and I've framed it using the dummy
) userItem method. However, I can't see how to make it understand that
) pressing return/enter is the same as clicking on the OK button.
)
) I'm calling IsDialogEvent, followed by DialogSelect in order to determine
) which dialogue the event is for. Thing is, DialogSelect 'helpfully'
) processes the event for me too. By the time I know both which key has been
) pressed and which dialogue it was pressed in, DialogSelect has already
) passed it on to the active TextEdit field.

One thing you can do is call the standard filter proc manually using the
CallModalFilterProc macro returned from GetStdFilterProc.  Come to think
of it, calling the StdFilterProc() function may do the trick.  Anyway,
do this before calling DialogSelect() and call it only when it returns
false (or is it true?  Damn, I can never remember).

Yes, I know these are usually used with modal dialogs, but they DO work
with modeless dialogs as well.  I use them in a SemiModalDialog() function
I whipped up.


) and all the standard edit combos (z, x, c, v). As sson as I try to find
) out which dialogue the keypresses are in, the events get process anyway
) and I'm left with an unwanted character sitting in my editText field.

You shouldn't pass keydown events with the cmdKey bit of the event.modifiers
field set to DialogSelect.  Trap these out and send them to your menu
command function.  Then, in your Edit menu handler, check to see if the
front window is a dialog.  If so, then call the appropriate DlgXXXX traps.


) Also, whilst I'm here, I'd like to ask for some help on pop-up menus under
) System 7. I haven't got all the documentation, but apparently there's a
) CDEF I can use in combination with PopUpMenuSelect(). Which CDEF is it,
) please? And how would I go about determining that information? This pop-up
) is to go in the same modeless dialogue as above, so I assume that what I
) need to do is get a handle to the CDEF and then do a SetDItem call - is
) that right?

The procID is 1009.  But there are a few variation codes and each field
in the CNTL resource means something special.  It's documented in Inside
Mac VI as well as one of the new Inside Macs (but I can't remember which).

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

---------------------------

>From [e-mail] (Rob Browning)
Subject: How difficult to create an AS wrapper for porting?
Date: Sun, 11 Dec 1994 13:18:40 -0600
Organization: The University of Texas at Austin

There are a number of unix tools that would be useful to have on the Mac
(indent comes to mind).  I was wondering how difficult it would be to
create a library representing a wrapper that could be used to encapsulate
the unix code, turning it into an AppleScriptable application.  It would
be nice to be able to write scripts like this (please excuse my naive AS
syntax):

tell application "WordCount" --i.e. wc
   run given parameters:"-l" stdin:"MyDrive:inputFile"
stdout:"MyDrive:outputFile"
end tell

or something like this.

If this were done, porting some of the unix tools to the mac could be much
more straightforward, and you could chain tools in a manner similar to the
way tools are combined in MPW and unix.  As it stands now, a number of
these tools have been ported, but it is difficult to combine the
standalone versions to do anything useful.

Does anyone have an idea how difficult this would be?

Thanks -- Rob

+++++++++++++++++++++++++++

>From [e-mail] (Julian Harris)
Date: Thu, 15 Dec 1994 18:21:54 +1300
Organization: Computer Science Department, UA

In article <[e-mail]>,
[e-mail] (Rob Browning) wrote:

> There are a number of unix tools that would be useful to have on the Mac
> (indent comes to mind).  I was wondering how difficult it would be to
> create a library representing a wrapper that could be used to encapsulate
> the unix code, turning it into an AppleScriptable application.  It would
> be nice to be able to write scripts like this (please excuse my naive AS
> syntax):
>
> tell application "WordCount" --i.e. wc
>    run given parameters:"-l" stdin:"MyDrive:inputFile"
> stdout:"MyDrive:outputFile"
> end tell
>
> or something like this.
>
> Does anyone have an idea how difficult this would be?

That could work. You'd 'subclass' the 'oapp' event so that its default
behaviour would be the same (no arguments), but if you give it others,i.e.
stdin and stdout parameters, it would accept them too. It could also do
something tricky with odoc events too, so you can drag a file onto the app
(which would then be the stdin source).

Because AppleEvents are sent through events, you'd have two basic states
of the program:

- the wrapper which hangs around for the oapp and odoc events (if there are any)
  and if none, brings up the standard ccommand thing that is supplied with
  Symantec and MW.

- the core app.

Actually it would be better to have the stdin, stdout, parameters, etc
sent in another event so you can do it again when the app is running.

But one of the biggest problems with getting unix programs to work is that
they rely on static initialisation of variables. That you have to do
manually, but I agree, it wouldn't be too difficult to do such a thing.
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Microsoft is not the answer.                    >  Julian Harris, Programmer   >
Microsoft is the question.                     >  Comp. Sci. Dept.     x8915  >
                                              >  The University of Auckland  >
NO is the answer.                            >  [e-mail]    >

+++++++++++++++++++++++++++

>From [e-mail] (Tim Gilbert)
Date: Thu, 15 Dec 1994 20:12:31 GMT
Organization: College of Marin, Kentfield, CA 94904

Rob Browning ([e-mail]) wrote:
: There are a number of unix tools that would be useful to have on the Mac
: (indent comes to mind).  I was wondering how difficult it would be to
: create a library representing a wrapper that could be used to encapsulate
: the unix code, turning it into an AppleScriptable application.  It would
: be nice to be able to write scripts like this (please excuse my naive AS
: syntax):

: tell application "WordCount" --i.e. wc
:    run given parameters:"-l" stdin:"MyDrive:inputFile"
: stdout:"MyDrive:outputFile"
: end tell

: or something like this.

This is something that's been kicking around my head for a long time; I
think it's a great idea.  Unfortunately I've never had the System 7 savvy
to work on it.  But here are a few of the ideas I've had:

 -- All the simple TextEdit editors in all of those unix ports would be
    unnecessary; stdin could read either from a window or a file (the ProIcon
    environment handles this very nicely).

 -- Code size could be drastically reduced; most of the file, console, etc
    stuff in the <ANSI> lib could be replaced by simple AppleEvent calls.
    Further, all apps would use the same (single) stio library, which
    would be essentailly a shared library.

 -- My ambition was to write a full ANSI lib that would be in the public
    domain, with strcpy, malloc, fprintf, etc, etc...  Unfortunately I
    don't have the time for any of that now.  But the advantages of
    bundling all those up into a shared library should be clear, I
    think.

Somewhere (perhaps the nic.switch.ch source archive?) is a package called
posixlib...  I haven't looked at it yet, but maybe it would provide some
good code to use as a base to start from...

Anyways, keep us all posted about what you come up with, if anything,
please...  Good luck!                           -- Tim

--
Tim Gilbert <> [e-mail] <> College of Marin, S.F. Bay Area

+++++++++++++++++++++++++++

>From [e-mail] (Rob Browning)
Date: Fri, 16 Dec 1994 18:57:04 -0600
Organization: The University of Texas at Austin

In article <[e-mail]>, [e-mail] (Tim
Gilbert) wrote:

> This is something that's been kicking around my head for a long time; I
> think it's a great idea.  Unfortunately I've never had the System 7 savvy
> to work on it.  But here are a few of the ideas I've had:
>
>  -- All the simple TextEdit editors in all of those unix ports would be
>     unnecessary; stdin could read either from a window or a file (the ProIcon
>     environment handles this very nicely).

Quite true.  It would really be nice if the wrapper could be constructed so that
these tools could have their stdin and stdout redirected to your favorite
text editor
(Alpha for me :>), and then you could use the editor's text windows as shell
windows to run the tools.  One of the nice things about this is that the tools
would only be taking up RAM when they are running (instead of the way that
MPW handles tools).  There could also be a flag that determines whether or not
the tool quits after a run or stays open waiting for the next command.

I've started looking into what it takes to create an applescriptable app,
(in IM: Interapplication Communications), and it looks like I'm certainly not
yet up to the task.  Hopefully I'll get some time, and can learn the stuff
I need to
know, but it looks like a substantial undertaking...

If anyone else gets the urge and knows this stuff better, feel free to go
ahead :>

--Rob.

+++++++++++++++++++++++++++

>From [e-mail] (Howard Jacobowitz)
Date: 17 Dec 1994 21:41:13 -0500
Organization: Rutgers University

[e-mail] (Rob Browning) writes:

>There are a number of unix tools that would be useful to have on the Mac
>(indent comes to mind).  I was wondering how difficult it would be to
>create a library representing a wrapper that could be used to encapsulate
>the unix code, turning it into an AppleScriptable application.  It would
>be nice to be able to write scripts like this (please excuse my naive AS
>syntax):

>tell application "WordCount" --i.e. wc
>   run given parameters:"-l" stdin:"MyDrive:inputFile"
>stdout:"MyDrive:outputFile"
>end tell

>or something like this.
>If this were done, porting some of the unix tools to the mac could be much
>more straightforward, and you could chain tools in a manner similar to the
>way tools are combined in MPW and unix.  As it stands now, a number of
>these tools have been ported, but it is difficult to combine the
>standalone versions to do anything useful.

>Does anyone have an idea how difficult this would be?

>Thanks -- Rob

I shouldn't think it would be too hard.  Actually, it would probably
be kind of interesting to work out.  I started something similar to
this once, but never really spent enough time on it to get it to work
decently.

+++++++++++++++++++++++++++

>From [e-mail] (Julian Harris)
Date: Mon, 19 Dec 1994 14:11:18 +1300
Organization: Computer Science Department, UA

In article <[e-mail]>,
[e-mail] (Rob Browning) wrote:

> In article <[e-mail]>, [e-mail] (Tim
> Gilbert) wrote:
>
> > This is something that's been kicking around my head for a long time; I
> > think it's a great idea.  Unfortunately I've never had the System 7 savvy
> > to work on it.  But here are a few of the ideas I've had:
> >
> >  -- All the simple TextEdit editors in all of those unix ports would be
> >     unnecessary; stdin could read either from a window or a file (the
ProIcon
> >     environment handles this very nicely).
>
> Quite true.  It would really be nice if the wrapper could be constructed
so that
> these tools could have their stdin and stdout redirected to your favorite
> text editor

<snip>

>
> If anyone else gets the urge and knows this stuff better, feel free to go
> ahead :>

Well, it does sound like with Apple events, and the proliferation of
scriptable apps, that it could work reasonably well. One day, in a distant
land, perhaps I could get around to it.

I'm just researching IAC myself, and have printed out the relevant
sections on Apple events, object descriptors, and recording (all 500 pages
of it :) and have got lots of neat ideas about how to write a scriptable
app. The first (which is extrememly revolutionary :) is to model your
application in terms of what apple event objects it is comprised of, and
their properties and elements they're associated with.

Perhaps when I have a bit more experience with Apple events I could get on
to this. It doesn't sound too hard I reckon.
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Microsoft is not the answer.                    >  Julian Harris, Programmer   >
Microsoft is the question.                     >  Comp. Sci. Dept.     x8915  >
                                              >  The University of Auckland  >
NO is the answer.                            >  [e-mail]    >

---------------------------

>From [e-mail] (Tony Cooper)
Subject: How to get Macintosh Name or Owner Name?
Date: 16 Dec 1994 06:20:03 GMT
Organization: Public Access Internet, Auckland New Zealand

How do you get the Macintosh Name or Owner Name? I have all the Inside Mac
bookks, all the snippets, and all the Develop Bookmark CDs. But I can't
find this one anywhere.

Someone, please put me out of my misery and give me a reference. Mail
to [e-mail].

Shouldn't Gestalt do this?

Thanks
Tony Cooper
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 17 Dec 1994 04:21:18 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <3crbil$54s@status>, [e-mail] (Tony Cooper) wrote:

< How do you get the Macintosh Name or Owner Name? I have all the Inside Mac
< bookks, all the snippets, and all the Develop Bookmark CDs. But I can't
< find this one anywhere.
<
< Someone, please put me out of my misery and give me a reference. Mail
< to [e-mail].
<
< Shouldn't Gestalt do this?
<
< Thanks
< Tony Cooper
< [e-mail]

You can call GetString() with these constants:

const short kChooserNameID = -16096;
const short kMachineNameID = -16413;

These 'STR ' resources are in the system file.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 16 Dec 1994 20:44:22 -0800
Organization: Internet for the Olympic Peninsula

In article <3crbil$54s@status>, [e-mail] (Tony Cooper) wrote:

> How do you get the Macintosh Name or Owner Name? I have all the Inside Mac
> bookks, all the snippets, and all the Develop Bookmark CDs. But I can't
> find this one anywhere.

'STR ' resource ID -16096 is the user name
'STR ' resource ID -16413 is the machine name

See page 1-127, IM More Mac Toolbox (I have the corner folded over).

'STR ' resource ID -8192 is the printer type (driver name) except when it
isn't.  One situation where it isn't is when QuickDraw GX printing is
installed, when 'STR ' -8192 is the name of the current default desktop
printer.

> Mail to [e-mail].
Done.
  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Caesar attended the Senate in a rented toga.
   [e-mail]

---------------------------

>From [e-mail] (Mark A. Matthews)
Subject: How to receive events in AppleScript script?
Date: Sun, 11 Dec 1994 12:05:46 -0700
Organization: XMission Public Access Internet (801 539 0900)


I'm trying to write a script which will receive events from Eudora when
mail arrives.  I can convince Eudora to send my script the events, but I
can't figure out how to write the part of the script that is to receive
the event from Eudora.

A fragment of AppleScript demonstrating this would help greatly.  Can
anyone provide one?

--
-Mark

+++++++++++++++++++++++++++

>From [e-mail] (Paul Boots)
Date: Mon, 12 Dec 1994 12:01:00 +0100
Organization: ELECTROGIG Europe

In article <[e-mail]>, [e-mail]
(Mark A. Matthews) wrote:

> I'm trying to write a script which will receive events from Eudora when
> mail arrives.  I can convince Eudora to send my script the events, but I
> can't figure out how to write the part of the script that is to receive
> the event from Eudora.
>
> A fragment of AppleScript demonstrating this would help greatly.  Can
> anyone provide one?
>
> --
> -Mark


Hi Mark,  below some code I tested with Eudora.  It will receive the notice
event sent by Eudora.


Paul Boots
[e-mail]

- --
CODE BEGINS
- --
on run

   --activate
   --start notifying when mail sent
   --tell application "Eudora1.5.1fc1-1.95" to start notifying
   set WhoIam to the (path to current application as alias)
   tell application "Eudora1.5.1fc1-1.95" to start notifying WhoIam when
mail sent

end run

on notice messages theMsgList
   tell me to activate
   display dialog "Eudora notified me that it has send the following
messages: " & ,
      return & theMsgList
end notice
- --
END OF CODE
- --

---------------------------

>From [e-mail] (Francois Pottier)
Subject: Jasik 12-08 Update available
Date: 10 Dec 1994 13:11:00 GMT
Organization: Ecole Normale Superieure, PARIS, France


Steve Jasik asked me to post this message here. Note that I am in no
way affiliated with Jasik Designs, I'm just a happy user of The Debugger...

- ------------------------------------------------------------------------------

12/8 Jasik Debugger patch Notes - Dec 8, 1994

To all Jasik Debugger users:

The file '12_08_Dbgr_Patch' is an Application which patchs the
9/30/94 version of The Debugger.

%%%%%JCurrent Fixes/changes - 12/8 %%%%%

% auto load CFM LIbraries that we are notified about
        Open Doc users:
        Name your .sym files as Libname.xSym and they will get loaded Automatically
        when the OpenDoc part loads.

FIX - Watchpoint to make more reliable, remove warning window

fix - Step Into $AAFE (_MixedModeMagic) traps ( 68K -> PPC transitions ) now works

fix - change Cursor handling to eliminate turds on PB 5xx Macs

fix - when Interrupting a Mac running PowerPC code, xfer to it

fix - stack crawl to handle both type of MixedMode switch frames
fix - Discipline & Block Zapping - account for Modern Memory Mgr
fix     - Discipline & ioNamePtr - names can be in ROM
fix -?stack - not processing 3rd arg properly
fix - addresses were truncated to 24 bit values in unstructured asm windows

%%%%%JCurrent Fixes/changes - 11/19 %%%%%

fix - delete Bkpt's from memory image when deleting a task

%%%%%JFixes/changes since 11/15 %%%%%

fix - off by 1 in Target Lib command changes - incorrect data seg addr

fix - add a 'ppat' resource to Dbgr so it doesn't clear DeskCPat

fix - ignore DiskEvents so we don't lose them when we stop at INIT time.

%%%%%JFixes/changes since 10/17/94 %%%%%

fix - auto unload PPC targeted tasks properly

fix - allow absolute address Breakpoints above 16 Meg
                                display instructions & Bkpts properly in asm windows

fix - not listing fields of array properly so they could be modified

fix - allow Local Vars window to retain it's All or 1 frame mode
                                when it becomes dynamic

fix - allow modification of vars in other than the 1st frame.
                                NOTE: You can't modify Reg Vars in other than Current proc.

fix - blowup in _CloseResFile when trying to do SysBeep in 7.5 on IIfx, IIci

fix - PACK 3 so we don't get an error trying to access the PowerTalk volumes

fix - Garbage task in task tbl due to MF's heap moving when Modern Mem Mgr
                also cleanup code in Add_AuxTask which was incorrect

% extend Target Lib to handle 68K Libs & libs with multiple exec segs

fix - ignore SameProcess calls inside Dbgr as Wacom are asshole's

fix - problems with Metrowerks .SYM files overflowing NTE limits, etc

fix - Undo processing in text windows & memory leaks
                        cmd-delete or Clear forces shrinking of the Text buffer

fix - screwed type processing when 1st type was a dup type

%%%%%JFixes/changes since 10/10/94 %%%%%J

fix - remove code to play with GetResource patch as it assumed Dbgr's
                patch was 1st on the chain.
                Fixes problems with System 7.5 & Apple Menu Options

fix - a bug in PPC WatchPoint that caused it to hang

% add ?stack(fba,stk_top,is_PPC) command to dump an arbitrary stack
        if stk_top = 0 then stk_top := fba + 0C00,
        is_PPC = 1 for stack that starts with PPC stack frames.
        NOTE:  This could be useful for Thread Mgr debugging.

% Cmd_Key_Plus flag - If FrontWindow is Read_only then 'Cmd key' is added
                to any Key press except 'e' and period.
                You may turn this option OFF with the 'Cmd_Key_Plus' flag.
        NOTE
                a) remove the PLI_Buf flag from your ROM.dsi
                b) This option is more convenient than Function Keys for stepping

fix - protect against OSDispatch calls inside The Debugger's environment
        by returning 'No such process' for GetFrontProcess, GetNextProcess, I
        Fixes problems with MS Word 6 and FileSharing, etc.

%%%%%JFixes/changes since 9/30/94 %%%%%J

fix - Metrowerks Global Vars above A5 now works.

fix - Allowing periods in the  middle of names broke 'Struct.field' in parser, etc
                Restrict name syntax to: 'xxx.nn' where n is a number

fix - handle 4 byte enums in SYM files correctly

Flag CFM Libraries in the Heap Display as: ' CFM Lib: pwpc'
        =-G - search for symName if addr is in a CFM Library or ROM (like Frown dcmd )

Change default NTE Cutoff to $CE00

fix - incorrect tabbing in writable windows, also set dialog box properly

fix - stepping into a JSR d(A5) didn't alway work

fix - MacApp Object displays - prefix window with task number (name too wide),
                make class tree work for specified subtree, fix Methods of for PPC tasks

fix - speed up Cmd-D 'by name' search by NOT searching for a ROM name
                        unless already in the ROM task

%%%%%JTo update your version of The Debugger%%%%%%:

A) Open up the folder 'Dbgr/Nosy files' and
   change the name of of the 9/30/94 version of 'The Debugger'
   to: '9/30/94 The Debugger'

B) Dbl-click on the UpdateMaker file '12_08_Dbgr_Patch'
   to create a new version of 'The Debugger'
         (in the 'Dbgr/Nosy files' folder).

% NOTE: If the patch program complains that FONT resources
% don't match, then try Booting with Extensions OFF
% (shift key down while booting) and try the Updater again.


You may verify that you are running the newer version
of The Debugger by checking the 4th line of the '-Notes-'
window when you re-boot with The Debugger installed.

It should read:
USR_SG =   nnnn The Debugger - V2.7.5-PPC 12/8/94
                                          -------
Steve Jasik
--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

---------------------------

>From [e-mail] (brianv)
Subject: Mounting Appleshare Volumes
Date: 7 Dec 1994 23:50:08 GMT
Organization: Division of Information Technology

Hello,
I have been fighting with my mac trying to get it to mount an
Appleshare volume located on an ethernet network using the command
PBVolumeMount().
However, I haven't had any luck.  Can anyone send me some code where
they have had success doing this?

Thanks,
Brian Vanderpool
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 11 Dec 1994 15:50:34 +0800
Organization: Department of Computer Science, University of Western Australia

In article <3c5hng$[e-mail]>, [e-mail]
(brianv) wrote:

>I have been fighting with my mac trying to get it to mount an
>Appleshare volume located on an ethernet network using the command
>PBVolumeMount().

Did this just the other day...

  function MountAFPVolume(zone, server, vol, user, password : Str32;
               var mountedVRefNum : integer) : OSErr;
    var
      info: AFPVolMountInfo;
      cur_offset: integer;

    function CopyString (s: Str32): integer;
    begin
      CopyString := cur_offset + 23;      (* 23 = header size - 1 (because
the AFPData array is 1 based) *)
      BlockMove(@s, @info.AFPData[cur_offset], length(s) + 1);
      cur_offset := cur_offset + length(s) + 1;
    end; (* CopyString *)

    var
      pb: ParamBlockRec;
      err : OSErr;
  begin
    mountedVRefNum := 0;
    info.length := sizeof(info);
    info.media := AppleShareMediaType;
    info.flags := 0;
    info.nbpInterval := 0;
    info.nbpCount := 0;
    info.uamType := kTwoWayEncryptPassword;
    cur_offset := 1;
    info.zoneNameOffset := CopyString(zone);
    info.serverNameOffset := CopyString(server);
    info.volNameOffset := CopyString(vol);
    info.userNameOffset := CopyString(user);
    info.userPasswordOffset := CopyString(password);
    info.volPasswordOffset := CopyString('');
    with pb do begin (* safe *)
      pb.ioBuffer := @info;
    end; (* with *)
    err := PBVolumeMount(@pb);
    if err = noErr then begin
      mountedVRefNum := pb.ioVRefNum;
    end; (* if *)
    MountAFPVolume := err;
  end; (* MountAFPVolume *)

Share and Enjoy.
--
Quinn "The Eskimo!"                   "Ah ha, the carnage begins!"

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 12 Dec 1994 00:40:15 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <3c5hng$[e-mail]>, [e-mail]
(brianv) writes:

>I have been fighting with my mac trying to get it to mount an Appleshare
>volume located on an ethernet network using the command PBVolumeMount().
>However, I haven't had any luck.  Can anyone send me some code where
>they have had success doing this?

Brian, Apple's sample code MoreFiles has a routine named
BuildAFPVolMountInfo which will correctly built the mounting record for
you. MoreFiles also has a high-level version of PBVolumeMount that you
might find useful.

If you need the user to enter their name and password, you can let the
system take care of that for you by using NewAliasMinimalFromFullPath and
then ResolveAlias.

- Jim Luther

---------------------------

>From [e-mail] (Eric Scouten)
Subject: PUZZLER: How to get to A5 world in _ExitToShell patch
Date: Tue, 06 Dec 1994 16:55:05 -0600
Organization: University of Illinois

Howdy,

I have an application that sets up lots of interrupt-level stuff
(particularly sound channels). These, of course, have lots of asynchronous
callback routines.
To avoid the problem of leaving these things hanging when somebody (often
myself, via the debugger or MacsBug) aborts the application via
ExitToShell, I'm writing an ETS patch.

All works fine when I do kill process from the MW Debugger, but *most* of
the time when I hit the programmer's switch and do "es" from MacsBug, the
A5 world is off the wall. (From what I can tell, I hit the NMI while the
Toolbox was doing something for my app.) I need A5 to get to my list of
things to close, but I can't figure any way to save a copy of A5 for
myself. Static variables won't do, since they're all A5-indexed; the usual
trick of extending the parameter block (for Time Manager tasks, etc., as
documented in Develop) won't work since ETS has no parameter block.

So I'm confused... anybody got bright ideas?

-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

Universities seem happiest when they are closest to anarchy.
   -Bill DiBrito

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 7 Dec 1994 00:38:17 GMT
Organization: University of Michigan

There is a lomem global called CurrentA5 which saves the valid A5 from the
current context.

That should do it.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Tue, 06 Dec 1994 21:15:08 -0600
Organization: University of Illinois

In article <3c305p$[e-mail]>, Matt Slot
<[e-mail]> wrote:

> There is a lomem global called CurrentA5 which saves the valid A5 from the
> current context.

Duhhh... of course. Thanks for reminding me. :)

Must have been the lack of sleep.

-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

We're putting out fires with gasoline.
   -David Bowie

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 06 Dec 1994 20:40:56 -0700
Organization: cellular

In article <[e-mail]>,
[e-mail] (Eric Scouten) wrote:

> I have an application that sets up lots of interrupt-level stuff
> (particularly sound channels)... To avoid the problem of leaving
> these things hanging (upon an unexpected call to) ExitToShell,
> I'm writing an ETS patch.
>
> All works fine when I do kill process from the MW Debugger, but *most* of
> the time when I hit the programmer's switch and do "es" from MacsBug, the
> A5 world is off the wall.

The programmer's switch induces an NMI regardless of the code being
executed. It may be the code from some other app, it may be trap code, it
may be one of your completion routines -- anything. So yes, A5 can be
wacky when you hit that NMI.

However, this is not a problem having to do with A5, really. The real
problem is the fact that you are inducing that NMI when code other than
that of your app is running. Doing an 'es' under these circumstances is
dangerous for a number of reasons, *not* the most important of which is
that A5 is not set up correctly (because you can easily fix that in your
patch by -- theoretically -- getting the "correct" value from the low
memory global CurrentA5). It may also be the case that your app's heap is
not the current heap, your app's copy of the low memory globals has not
been swapped in, and a number of other things, some of which only Apple
engineers are aware.

So the problem is not your patch but the timing of your 'es' command.

What I do to insure everything is set up correctly for me to do an 'es'
against any app is to drag a window or pull down a menu, keeping the mouse
button held down, invoke MacsBug (most often by holding down the command
key with my free thumb and depressing the power key with my nose), type
'atba', command-G, and release the mouse. (Probably I had to release the
mouse to type the MacsBug command, but you get the idea.) The click/hold
sequence ensures that the front app is the current app. As soon as the app
calls its next trap (probably the one right after DragWindow or
MenuSelect), MacsBug steps in. Then I know it's probably a little more
safe to do 'es'. If it's my app, then I know for sure it's safe, because
I've patched ExitToShell like you are doing. :-)

+++++++++++++++++++++++++++

>From [e-mail] (Alex Maluta)
Date: Wed, 7 Dec 1994 09:38:40 GMT
Organization: /etc/organization

Eric,

> All works fine when I do kill process from the MW Debugger, but *most* of
> the time when I hit the programmer's switch and do "es" from MacsBug, the
> A5 world is off the wall. (From what I can tell, I hit the NMI while the
> Toolbox was doing something for my app.) I need A5 to get to my list of
> things to close, but I can't figure any way to save a copy of A5 for
> myself. Static variables won't do, since they're all A5-indexed; the usual
> trick of extending the parameter block (for Time Manager tasks, etc., as
> documented in Develop) won't work since ETS has no parameter block.
>

I haven't tried this in exactly your case, but a quick look at TCL 1.1.3
(which does patch ExitToShell) shows that they get at globals by simply
calling SetCurrentA5().  It's too early in the morning for me to figure
out if this is exactly what you're looking for, but hopefully it'll help.

-Alex

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wesley)
Date: 7 Dec 1994 15:41:48 GMT
Organization: Punch Deck Consulting

In article <[e-mail]>
[e-mail] (Eric Scouten) writes:

> All works fine when I do kill process from the MW Debugger, but *most* of
> the time when I hit the programmer's switch and do "es" from MacsBug, the
> A5 world is off the wall. (From what I can tell, I hit the NMI while the
> Toolbox was doing something for my app.) I need A5 to get to my list of
> things to close, but I can't figure any way to save a copy of A5 for
> myself. Static variables won't do, since they're all A5-indexed; the usual
> trick of extending the parameter block (for Time Manager tasks, etc., as
> documented in Develop) won't work since ETS has no parameter block.

Try using SetCurrentA5.

rmgw

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 7 Dec 1994 20:49:06 GMT
Organization: University of Michigan

Pete Gontier, [e-mail] writes:
 > However, this is not a problem having to do with A5, really. The real
 > problem is the fact that you are inducing that NMI when code other than
 > that of your app is running. Doing an 'es' under these circumstances is
 > dangerous for a number of reasons, *not* the most important of which is
 > that A5 is not set up correctly (because you can easily fix that in your
 > patch by -- theoretically -- getting the "correct" value from the low
 > memory global CurrentA5). It may also be the case that your app's heap is
 > not the current heap, your app's copy of the low memory globals has not
 > been swapped in, and a number of other things, some of which only Apple
 > engineers are aware.

If I use the debugger to 'es', it will kill the current app -- not the
owner of the interrupt based routine you are in -- based on the switched in
heap. You shouldn't have to worry about being exited when your app isn't
in context. (I believe this, but have no confirmation).

Doing an 'es' from anyone else's context should be safe enough to your
interrupt routines if you have placed them in your heap or the system heap --
but don't trust another app's heap, that would be bad. If you don't
care for cleanliness and don't depend on globals from your app's heap,
you can place your buffers/routines in the system heap. When you drop out,
they will simply keep operating -- I know its not pretty, but fairly quick
and safe.

The only issue is to restore a valid globals context when you get the
'es' when your app is current, so that you can get the info about those
routines you installed.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (Reinder Verlinde)
Date: Thu, 8 Dec 1994 19:00:32 GMT
Organization: Rijksuniversiteit Utrecht

In article <[e-mail]>, [e-mail] (Pete
Gontier) wrote:

> ...
>
> What I do to insure everything is set up correctly for me to do an 'es'
> against any app is to drag a window or pull down a menu, keeping the mouse
> button held down, invoke MacsBug (most often by holding down the command
> key with my free thumb and depressing the power key with my nose), type
> 'atba', command-G, and release the mouse. (Probably I had to release the
> mouse to type the MacsBug command, but you get the idea.) The click/hold
> sequence ensures that the front app is the current app. As soon as the app
> calls its next trap (probably the one right after DragWindow or
> MenuSelect), MacsBug steps in. Then I know it's probably a little more
> safe to do 'es'. If it's my app, then I know for sure it's safe, because
> I've patched ExitToShell like you are doing. :-)
>
> ...

The easier way to obtain the same result is to use a FKEY to enter MacsBug.
To prevent nasty surprises when MacsBug is not installed (which should not
happen often) one should use a FKEY like:

#define MacJmp 0x120

void main()
{
    asm
    {
        move.l  MacJmp,D0
        and.l   #0x7FFFFFFF,D0
        beq.s   @noDebuggerPresent
        dc.w    _Debugger
        rts

    noDebuggerPresent:
        Move.w  #0x09,-(sp)
        dc.w    _SysBeep
//      rts     automatically included at end by Think C
    }
}

or in hex (can be pasted into an empty FKEY resource in ResEdit):

2038012002807FFFFFFF6704A9FF4E753F3C0009A9C84E75

I don't know whether it works with all debuggers, but it does work
fine for me (I got the information on Debugger detection from an Apple
Technote called 'PT 535 - MacsBug Q&As'. I'm not sure whether I
followed the note completely; I remember detecting an inconsistency
between its text and some Macs I examined)

Reinder Verlinde

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 13 Dec 1994 15:24:44 -0700
Organization: cellular

In article <[e-mail]>,
[e-mail] (Reinder Verlinde) wrote:

> The easier way to obtain the same result is to use a FKEY to enter MacsBug.

Yes, but...

   (1) FKEYs don't work unless GNE is getting called periodicially.
   (2) I *like* hitting the power key with my nose. Who are you to
       tell me I shouldn't? :-)

--

 Pete Gontier // MacZealotry, Ink. // [e-mail]

 Where do I want to go today? Anywhere but Chicago.

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 9 Dec 1994 23:39:27 GMT
Organization: Bowling Green State University

[e-mail] (Eric Scouten) writes:
> Howdy,
>
> I have an application that sets up lots of interrupt-level stuff
> (particularly sound channels). These, of course, have lots of asynchronous
> callback routines.
> To avoid the problem of leaving these things hanging when somebody (often
> myself, via the debugger or MacsBug) aborts the application via
> ExitToShell, I'm writing an ETS patch.

  The following code works well for me...

  There are two functions to this.  The first is InstallExitToShellPatch
which takes a procedure pointer for the procedure that you want to
to be called when the app is quitting.  InstallExitToShellPatch patches
ExitToShell to call the second function, CallExitToShells.

How it works:

  InstallExitToShellPatch builds a list of procedure pointers.  Every
time that you call InstallExitToShellPatch, the procedure is added
to the queue.  When your app quits and the CallExitToShells procedure
is called, it sets up the A5 world and then starts calling the procedures
in the list (last in, first out).

  Three files are included.  ExitToShell Patch.c and ExitToShell Patch.h,
as well as a small file (named main.c) that demonstrates how to use
the routines.

Enjoy,

  Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

            Mighty 'Moof-in' PowerPC Ranger

/*
        ExitToShell Patch.h

        Header file for ExitToShell Patch.c

*/

#pragma once

#ifndef __H_ExitToShell_Patch__
#define __H_ExitToShell_Patch__

#include <Memory.h>
#include <SegLoad.h>

typedef pascal void (*ExitToShellProcPtr)(void);

enum {
        uppExitToShellProcInfo = kPascalStackBased
};

#if USESROUTINEDESCRIPTORS
typedef UniversalProcPtr ExitToShellUPP;

#define CallExitToShellProc(userRoutine)        \
        CallUniversalProcPtr((UniversalProcPtr)(userRoutine),uppExitToShellProcInfo)
#define NewExitToShellProc(userRoutine) \
        (ExitToShellUPP)NewRoutineDescriptor((ProcPtr)(userRoutine),uppExitToShellProcInfo,\
                GetCurrentISA())

#else
typedef ExitToShellProcPtr ExitToShellUPP;

#define CallExitToShellProc(userRoutine)        \
        (*(userRoutine))()
#define NewExitToShellProc(userRoutine) \
        (ExitToShellUPP)(userRoutine)
#endif

#define DisposeExitToShellProc(userRoutine)\
        DisposeRoutineDescriptor(userRoutine)

#if defined(powerc)||defined(__powerc)
#pragma options align=mac68k
#endif
struct ExitToShellUPPList{
        struct ExitToShellUPPList* nextProc;
        ExitToShellUPP userProc;
};
#if defined(powerc)||defined(__powerc)
#pragma options align=reset
#endif

typedef struct ExitToShellUPPList ExitToShellUPPList,* ExitToShellUPPListPtr,** ExitToShellUPPHdl;

#if defined(powerc)||defined(__powerc)
#pragma options align=mac68k
#endif
struct ExitToShellDataStruct{
        unsigned long a5;
        short numUserProcs;
        ExitToShellUPPList* userProcs;
        ExitToShellUPP oldProc;
};
#if defined(powerc)||defined(__powerc)
#pragma options align=reset
#endif

typedef struct ExitToShellDataStruct ExitToShellDataRec,* ExitToShellDataPtr,** ExitToShellDataHdl;

extern ExitToShellDataPtr gExitToShellData;

#ifdef __cplusplus
extern "C" {
#endif

OSErr InstallExitToShellPatch(ExitToShellProcPtr newProc);
static pascal void CallExitToShells(void);

#ifdef __cplusplus
}
#endif

#endif



/****************  End Of File! ***************/


/*
        ExitToShell Patch.c

        Patches ExitToShell to call a user routine.  With the advent of UPPs and MixedMode, it gets
        harder to patch things correctly.  Anyway, InstallExitToShellPatch takes an 'old' ProcPtr and
        creates the necessary UPP which NSetTrapAddress now requires.  Hopefully everything is
        done correctly... ;-)  CallExitToShells, the intermediary procedure, ensures that A5 is set
        up correctly for the application before calling the custom ExitToShell routine.

        8/14/94 dn - Created.

        11/31/94 dn - Major modifications!
                Modified to allow multiple ExitToShell patches.  Basically, this just builds a list of procedures to
                call before exiting the program.
*/

#include "ExitToShell Patch.h"

static ExitToShellDataPtr gExitToShellData=(ExitToShellDataPtr)0L;

/*
        InstallExitToShellPatch

        Installs the ExitToShell patch (obviously ;-).  In the data structure for gExitToShellData is stored the
        current value of the A5 register, the UPP for the routine that should be called first, then the UPP for
        the routine that was originally there.  ExitToShell is then patched to call the 'CallExitToShells' which
        handles all of the garbage for setting up the A5 register, etc., before calling the two routines.

        (patching ExitToShell info/example comes from TCL 1.1.3 CApplication.c, ) Symantec, Inc.)
*/
OSErr InstallExitToShellPatch(ExitToShellProcPtr newProc){
        short etsTrap;
        ExitToShellUPP oldETS,newETS,callETS;
        ExitToShellUPPListPtr lp;
        long oldETSTrap,newETSTrap;
        OSErr err;

        if (gExitToShellData==(ExitToShellDataPtr)0L){
                // the patches have not been initialized, set it up first...

                // allocate the memory to hold the information...
                gExitToShellData=(ExitToShellDataPtr)NewPtr(sizeof(ExitToShellDataRec));

                // save the value of register a5
                gExitToShellData->a5=SetCurrentA5();

                // init the number of user procs.
                gExitToShellData->numUserProcs=0;
                gExitToShellData->userProcs=(ExitToShellUPPList*)0L;

                // now set up the UPP for the original ExitToShell
                etsTrap=_ExitToShell & 0x3ff;                                                           // set up trap value...
                callETS=NewExitToShellProc(CallExitToShells);                                   // get the UPP for intermediary proc
                oldETS=(ExitToShellUPP)NGetTrapAddress(etsTrap,ToolTrap);               // get the old trap UPP...
                NSetTrapAddress((UniversalProcPtr)callETS,etsTrap,ToolTrap);    // set to the intermediary proc
                gExitToShellData->oldProc=oldETS;                                                       // save the old ETS UPP

        }

        // get the upp for the new replacement proc
        newETS=NewExitToShellProc(newProc);

        // allocate a new node...
        lp=(ExitToShellUPPListPtr)NewPtrClear(sizeof(ExitToShellUPPList));
        lp->userProc=newETS;

        // put it into the chain...
        lp->nextProc=gExitToShellData->userProcs;
        gExitToShellData->userProcs=lp;
        gExitToShellData->numUserProcs++;

        return noErr;
}

/*
        CallExitToShells

        First this routine calls the user's ExitToShell routines, then it calls the original
        ExitToShell trap routine.  That's why it is referred to as the intermediary procedure
        in InstallETSPatch.
*/
static pascal void CallExitToShells(){
        OSErr err,err2;
        long oldA5=SetCurrentA5(); // get the current value for register A5 and set it to the application's A5
        ExitToShellUPP oldETS;
        ExitToShellUPPListPtr nextProc,curProc;

        SetA5(gExitToShellData->a5);

        if (gExitToShellData->numUserProcs>0){
                // call the user's routines

                // get the first routine
                curProc=gExitToShellData->userProcs;

                // loop though the procedures...
                do {
                        // set up for the next routine
                        nextProc=curProc->nextProc;

                        // call the procedure
                        CallExitToShellProc(curProc->userProc);

                        // dispose of the UPP
                        DisposeExitToShellProc(curProc->userProc);

                        // dispose of the list entry
                        DisposePtr((Ptr)curProc);

                        curProc=nextProc;
                } while (curProc!=(ExitToShellUPPListPtr)0L);
                // done!
        }

        // prepare to call the original ExitToShell
        oldETS=gExitToShellData->oldProc;

        // dispose of the memory gExitToShellData holds
        DisposePtr((Ptr)gExitToShellData);

        // restore the old a5
        SetA5(oldA5);

        // now call the original ExitToShell
        CallExitToShellProc(oldETS);

        return;
}



/***********  End Of File! **************/


/*
        main.c

*/

#include "ExitToShell Patch.h"

pascal void proc1(void);
pascal void proc2(void);
pascal void proc3(void);

main(){

        InitMac();// self explanatory

        InstallExitToShellPatch(proc1);

        InstallExitToShellPatch(proc2);

        InstallExitToShellPatch(proc3);

}

pascal void proc1(){
        long time;

        SysBeep();
        Delay(120,&time); // needed to get the beeps to happen
}

pascal void proc2(){
        long time;

        SysBeep();
        SysBeep();
        Delay(120,&time); // needed to get the beeps to happen
}

pascal void proc3(){
        long time;

        SysBeep();
        SysBeep();
        SysBeep();
        Delay(120,&time); // needed to get the beeps to happen
}


+++++++++++++++++++++++++++

>From [e-mail] (Phil Shapiro)
Date: Fri, 16 Dec 1994 10:07:02 -0500
Organization: Symantec Corp.

In article <3caprf$[e-mail]>, [e-mail] (bgsuvax) wrote:

| [e-mail] (Eric Scouten) writes:
| > I have an application that sets up lots of interrupt-level stuff
| > (particularly sound channels). These, of course, have lots of asynchronous
| > callback routines.
| > To avoid the problem of leaving these things hanging when somebody (often
| > myself, via the debugger or MacsBug) aborts the application via
| > ExitToShell, I'm writing an ETS patch.
|
|   The following code works well for me...
|
|   There are two functions to this.  The first is InstallExitToShellPatch
| which takes a procedure pointer for the procedure that you want to
| to be called when the app is quitting.  InstallExitToShellPatch patches
| ExitToShell to call the second function, CallExitToShells.
|
| How it works:
|
|   InstallExitToShellPatch builds a list of procedure pointers.  Every
| time that you call InstallExitToShellPatch, the procedure is added
| to the queue.  When your app quits and the CallExitToShells procedure
| is called, it sets up the A5 world and then starts calling the procedures
| in the list (last in, first out).
|
|   Three files are included.  ExitToShell Patch.c and ExitToShell Patch.h,
| as well as a small file (named main.c) that demonstrates how to use
| the routines.

Anyone who has THINK C or Symantec C++ already has this -- it's called
"atexit()". If you register a function with atexit(), it's called at
ExitToShell time with the correct A5, automatically.

It doesn't support PowerPC patching of ETS, though. I believe that the CDK
comes with a PowerPC version of atexit() that uses __term instead of
patching ETS.

   -phil

+++++++++++++++++++++++++++

>From [e-mail] (bgsuvax)
Date: 16 Dec 1994 19:49:08 GMT
Organization: Bowling Green State University

[e-mail] (Phil Shapiro) writes:
>
> Anyone who has THINK C or Symantec C++ already has this -- it's called
> "atexit()". If you register a function with atexit(), it's called at
> ExitToShell time with the correct A5, automatically.

  Yes, but:

    1. you need TC or SymC++ (I do)
    2. you need the ANSI baggage

  It was mostly for #2 that I put the code together.  I have the
UPP code worked out for PPC patching, but like you said I am not
sure that it is the best method for PPC code...

Dave

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

            Mighty 'Moof-in' PowerPC Ranger


---------------------------

>From [e-mail] (Howard Katz)
Subject: Password for mounting remote volumes
Date: Mon, 28 Nov 1994 12:11:47 -0800
Organization: Enigmatic Software

Can someone tell me what a volume password is? Let me provide a little
context for the question.

We need to periodically automount remote servers on our network to ship
files over to them for archiving purposes. We need to do this transparently
without user intervention, so I'd like to use PBVolumeMount() to remount a
server, passing in saved mounting information from a prior session. This
seems fairly straightforward.

IM mentions a caveat, however, that System 7 filesharing software (which we
use) will not pass the volume password along with the PBVolumeMount() call.
My question is:

(1) What _is_ a volume password? All I currently know about and have access
to is the user password, and

(2) Does this mean I can't do what I want to do?

Any help would be much appreciated.

Thanks in advance,

Howard Katz
- --
Time flies like an arrow.
Fruit flies like a banana.

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 12 Dec 1994 01:15:34 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Howard Katz) writes:

>IM mentions a caveat, however, that System 7 filesharing software (which
>we use) will not pass the volume password along with the PBVolumeMount()
>call. My question is:
>
>(1) What _is_ a volume password? All I currently know about and have
>access to is the user password, and

Volume passwords are an optional feature of the AppleTalk Filing Protocol.
 It's so optional, that the AppleShare and File Sharing file servers don't
support it. There may be non-Apple AFP servers that support volume
passwords, but I don't know which ones.  It's kind of a stupid feature
since the password is sent to the server "clear text" (no encryption).

The note in IM: Files about volume passwords and PBVolumeMount only
pertains to older versions of the AppleShare client (the AppleShare
Chooser extension).  The problem was fixed in the AppleShare 3.0 client
and all laters versions of the AppleShare client (i.e., the clients that
shipped with System 7.1 and later, and with AppleShare Pro and 4.0.x).

>(2) Does this mean I can't do what I want to do?

Nope, not at all. Since you'll rarely even find a network volume with a
volume password, you probably don't even have to worry about it.  System 7
has little support for volume passwords - in fact, the Alias Manager
doesn't support them.

- Jim Luther

---------------------------

>From [e-mail] (Jim Sather)
Subject: SUMMARY: MacTCP Performance Problems
Date: Wed, 14 Dec 1994 20:42:07 GMT
Organization: Microsoft Corporation


About a week ago I asked for help/suggestions on how to speed up a TCP/IP
transport.  Here's a quick run down on the suggestions received.  It turns
out that the push flag was my problem.

-Jim

Robert Mah  <[e-mail]> wrote:
- -------------------------------------------------------
MacTCP is fairly sensitive to buffer space.   Try allocating a LOT more
space for the receive buffer when you create the stream.  Another thing
you might want to try is to use the TCPNoCopyRcv receive calls instead
of the TCPRcv call.

Also, make sure you are setting the "push" flag for TCPSend at the
appropriate times.  I think if you set it too often, you get lot's of
"smaller" packets instead of a few "larger" ones.  When to do this is
very application specific in nature.

Finally, you *are* calling MacTCP asynchronouslly aren't you?  And you
*are* using asych file mgr calls too, right?

Eric Scouten  <[e-mail]> wrote:
- ----------------------------------------------------------
You have to do a lot of funny business with MacTCP to get good performance
from it. Try playing with such parameters as the buffer size, number of
entries in the RDS/WDS. Also, you can issue multiple read/write commands;
doing so may help performance.

In my experience, MacTCP maxes out at about 410KB/second on an otherwise
quiet Ethernet. This is in line with Apple's advertising copy for MacTCP,
and suggests that there is some inherent slowness in MacTCP.


ttuck  <[e-mail]> wrote:
- ----------------------------------------------------
You might be suffering from the "infinite slowdown problem" that
plagues MacTcp up to version 2.0.4.

I have noticed an increase in speed of my favourite netapps since the
upgrade.

You can FTP a patcher from seeding.apple.com. You apply the patch to a
"virgin" copy of 2.0.4.

It fixes a whole swag of bugs including a nasty one with DNS that could
hose it if the DNS had a lot to say ! :-)


---------------------------

>From [e-mail] (Tom Bryce)
Subject: [Q] How to find parameter info for traps
Date: 11 Dec 1994 18:25:48 GMT
Organization: Duke Med


I have a copy the Develop CD #17 with the old Inside Macs I-VI on it,
as well as files, toolbox, toolbox essentials, and so on from the new
Inside Macs.

Can anyone tell me where I should look to find information on parameter
info for traps? For example, if I were to patch _MountVol, in which
registers would the parameters for _MountVol be passed, and how should
I return a return value? Push an OSErr onto the stack??

Thanks for any help.

- ----------------------------------------------------------------------

Tom Bryce
for PGP public key finger [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Sun, 11 Dec 1994 12:46:03 -0600
Organization: metrowerks, inc.

In article <3cfg7c$[e-mail]>, [e-mail] (Tom Bryce) wrote:

> Can anyone tell me where I should look to find information on parameter
> info for traps? For example, if I were to patch _MountVol, in which
> registers would the parameters for _MountVol be passed, and how should
> I return a return value? Push an OSErr onto the stack??

My advice is to dissect the relevant header files. For example, in
<Files.h>, there is the following declaration, which gives 68K register
declarations:

#if !GENERATINGCFM
#pragma parameter __D0 PBMountVol(__A0)
#endif
extern pascal OSErr PBMountVol(ParmBlkPtr paramBlock)
 ONEWORDINLINE(0xA00F);


(NOTE: This is from the new Universal Headers 2.0, but the old headers
should look somewhat similar.)

In general, the IM volumes concentrate more on providing info to those who
are *using* the traps, rather than those who are patching them. When you
get into patching, you may have to do some sleuthing to get the info and
then experiment to ensure that you're getting the right parameters in the
right places.

-es

__________________________________________________________________________
Eric Scouten <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Tom Bryce)
Date: 11 Dec 1994 20:31:25 GMT
Organization: Duke Med

In article <[e-mail]>
[e-mail] (Eric Scouten) writes:

> In article <3cfg7c$[e-mail]>, [e-mail] (Tom Bryce) wrote:
>
> > Can anyone tell me where I should look to find information on parameter
> > info for traps? For example, if I were to patch _MountVol, in which
> > registers would the parameters for _MountVol be passed, and how should
> > I return a return value? Push an OSErr onto the stack??
>
> My advice is to dissect the relevant header files. For example, in
> <Files.h>, there is the following declaration, which gives 68K register
> declarations:
>
> #if !GENERATINGCFM
> #pragma parameter __D0 PBMountVol(__A0)
> #endif
> extern pascal OSErr PBMountVol(ParmBlkPtr paramBlock)
>  ONEWORDINLINE(0xA00F);
>
>

Can I follow up with a question about how to interpret the following
header, just grabbed at random from Files.h

pascal OSErr PBClose(ParmBlkPtr paramBlock,Boolean async);
#pragma parameter __D0 PBCloseSync(__A0)
pascal OSErr PBCloseSync(ParmBlkPtr paramBlock)
    = 0xA001;
#pragma parameter __D0 PBCloseAsync(__A0)
pascal OSErr PBCloseAsync(ParmBlkPtr paramBlock)
    = 0xA401;

The first declaration (PBClose) seems to be for a close command. The
boolean seems to refer to whether it is being called asyncronously or
not, or in flow terms, whether the PBCloseSync or PBCloseAsync was
being called.

Suppose I were patching the PBClose command, for example, just to give
a sysbeep whenever a file is closed. Files.h did not give an address
for a trap for PBClose, the above is all it had. Should I then patch
two traps, one for PBCloseSync, and another for PBCloseAsync? And where
is the decision being made to call one or the other? Is there a trap
PBClose that is first called which then interprets the Boolean async
and calls one of the other two?

Am I correct in assuming A0 points to the parameters for these two
routines, and D0 should hold the result code they return when they are
finished?

Also, if PBClose has its own trap, what does the parameter block look
like? There are *two* arguments to PBClose here. So, for example, does
A0 point to a chunk of memory in which first a ParmBlkPtr is located,
then sequentially thereafter one byte of Boolean? So *((unsigned char
*)A0+sizeof(ParmBlkPtr)) would point to the Boolean parameter?

If it sounds like I'm a total neophyte, I am. :-) I have the FAQ on
init writing and some sample code, but nowhere have I seen explained
how to handle these parameter issues.

Thanks

Tom

- ----------------------------------------------------------------------

Tom Bryce
for PGP public key finger [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Sun, 11 Dec 1994 15:15:30 -0600
Organization: metrowerks, inc.

In article <3cfnit$[e-mail]>, [e-mail] (Tom Bryce) wrote:

[Initial question & my response deleted]

> Can I follow up with a question about how to interpret the following
> header, just grabbed at random from Files.h
>
> pascal OSErr PBClose(ParmBlkPtr paramBlock,Boolean async);
> #pragma parameter __D0 PBCloseSync(__A0)
> pascal OSErr PBCloseSync(ParmBlkPtr paramBlock)
>     = 0xA001;
> #pragma parameter __D0 PBCloseAsync(__A0)
> pascal OSErr PBCloseAsync(ParmBlkPtr paramBlock)
>     = 0xA401;
>
> The first declaration (PBClose) seems to be for a close command. The
> boolean seems to refer to whether it is being called asyncronously or
> not, or in flow terms, whether the PBCloseSync or PBCloseAsync was
> being called.

Ahhh... now you're hitting on some of the complexity of Macintosh system
calls. As you suspectd, PBClose is actually a piece of glue code in the
compiler's library that dispatches the call to the PBCloseSync or
PBCloseAsync trap based on the value of the boolean parameter.

BUT.. the fun's not over yet: The A001 and A401 actually get dispatched to
the *SAME* address (the _Close, 0x001 in OS trap dispatch table). The
routine that implements these traps (actually part of the Device Manager,
although the File Manager shares the traps) then looks at the trap word to
determine how it should respond to the call.

Fun, huh?

So for your application, you should patch the _Close trap. Both sync &
async calls will be routed to your patch. HOWEVER, you should know that
you'll *also* be getting requests to close *devices*, so you'll have to
some work to decode the param block before declaring that a close file was
executed.


> Suppose I were patching the PBClose command, for example, just to give
> a sysbeep whenever a file is closed.

DANGER WILL ROBINSON... SysBeep cannot be called from interrupt-level
code. The asynchronous flavor of _Close (and all the other file/device
calls) *can* be called from interrupt code (even if your app doesn't do
it, some other system process is likely to). So you'll have to figure some
other debugging method.


> Files.h did not give an address
> for a trap for PBClose, the above is all it had.

As I said, PBClose is merely a bit of glue code. In the new Universal
Headers (shipping on CW/5), it's been replaced by a macro, so the compiler
can optomize away the extra call if a constant is given for the async
parameter. It looks like this:

  #define PBClose(pb, async) ((async) ? PBCloseAsync(pb) : PBCloseSync(pb))


> Am I correct in assuming A0 points to the parameters for these two
> routines, and D0 should hold the result code they return when they are
> finished?

Yes. This is generally true for all of the "low-level" file/device manager
calls. (These are the calls that have PB at the start of their names.)

-es

__________________________________________________________________________
Eric Scouten <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 11 Dec 1994 16:33:22 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Eric Scouten) wrote:

Eric Scouten sez:
>
> As I said, PBClose is merely a bit of glue code. In the new Universal
> Headers (shipping on CW/5), it's been replaced by a macro, so the compiler
> can optomize away the extra call if a constant is given for the async
> parameter. It looks like this:
>
>   #define PBClose(pb, async) ((async) ? PBCloseAsync(pb) : PBCloseSync(pb))
>
That's also the headers I have in my MPW installation (from E.T.O. 15).

For PPC, there really are two calls into the shared library:  PBCloseAsync
and PBCloseSync...the macro is a clever way to separate them out at
compile time, and doesn't get in the way of setting up the bit in the trap
for 68K.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Caesar attended the Senate in a rented toga.
   [e-mail]

---------------------------

>From [e-mail] (Byron Han)
Subject: string constants in Metrowerks C code resource?
Date: Thu, 8 Dec 1994 07:40:57 GMT
Organization: Institute for Astronomy, University of Hawaii

How does one get string constants to work in 68K code resources in
Metrowerks?   I used to be able to do this just fine in MPW but now I am
stuck.  The PPC side of the code resource works just fine with the
embedded string constants but the 68K side is broken...

Thanks in advance.

BH

--
Byron Han * Institute for Astronomy * University of Hawaii at Manoa
  2680 Woodlawn Drive * Honolulu HI 96822 * [e-mail]
      WWW: http://galileo.ifa.hawaii.edu/~sped/byronhan.html
                eWorld: BYRONHAN * AOL: BYRON Han

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 09 Dec 1994 08:18:40 -0800
Organization: Internet for the Olympic Peninsula

In article <han-0712942140570001@128.171.75.8>, [e-mail] (Byron
Han) wrote:

> How does one get string constants to work in 68K code resources in
> Metrowerks?   I used to be able to do this just fine in MPW but now I am
> stuck.  The PPC side of the code resource works just fine with the
> embedded string constants but the 68K side is broken...

See the sample CODE resources folder.  Metrowerks follows THINK's idea of
using register A4 to point to the globals (but the details are
different).  String constants are just globals to THINK and
CodeWarrior...not handled with the special embed in the code and reference
via the PC as MPW can be told to do.  [Frankly, I prefer MPW's way.]

  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Caesar attended the Senate in a rented toga.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Stadtherr)
Date: Mon, 12 Dec 1994 03:24:25 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Byron Han) writes:

>How does one get string constants to work in 68K code resources in
>Metrowerks?   I used to be able to do this just fine in MPW but now I am
>stuck.  The PPC side of the code resource works just fine with the
>embedded string constants but the 68K side is broken...

>Thanks in advance.

>BH

Are you trying something like:

void CodeResourceMain (void)
{
        StringPtr theString = "\pThis is a string";
        ...
        oldA4 = SetUpA4();
        ...
        RestoreA4 (oldA4);
}

If so, you'll need to move the assignment of the StringPtr inside the
SetUpA4() call.  This is because the string globals are referenced from
A4 under MetroWerks.  This worked under THINK C, I believe, since THINK
code resources always started with A0 pointing to the start of the
resource.

-Eric Stadtherr
 Ootinta Software

---------------------------

End of C.S.M.P. Digest
**********************